By now you've probably seen Windows 95, and, like most Windows programmers, you've probably heard a great deal about how different it's going to be to write applications for this new environment. However, many elements of Windows 95 are simply "feature upgrades" to components of Windows 3.1.
One example of this phenomenon is the Windows 95 Registry. Described by some as a developer's version of the WIN.INI file, the Registry is actually just an up-to-date version of the Windows 3.1 Registration Database.
If you didn't know that Windows 3.1 had something called the Registration Database, you're not alone. Many Windows programmers are unfamiliar with this element of the Windows architecture.
In this article, we'll show how you can view the contents
of the Windows 3.1 Registration Database in different ways, we'll
tell you how the Registration Database affects File Manager associations,
and we'll demonstrate how you can define these associations
when your installation program installs an application. In future
issues, we'll take a closer look at the OLE mechanisms
that the Registration Database makes possible, and we'll
examine the Windows 95 Registry to see how it grew out of the
Windows 3.1 Registration Database.
In Windows 3.1, the Registration Database exists in a single file named REG.DAT. This file contains several hierarchical elements, which together provide file associations in File Manager, links between programs using Dynamic Data Exchange (DDE), and the foundation for OLE operations.
Unlike WIN.INI, the REG.DAT file isn't a text file you can view with Notepad. However, Windows does include an appropriate application for viewing the Registration Database, REGEDIT.EXE.
The REGEDIT application provides three separate interfaces: standard, verbose, and silent. The first interfacethe one you'll see if you double-click REGEDIT.EXE in File Managerdisplays user-level information, as shown in Figure A. This interface is useful for allowing users to specify custom associations between applications and documents.
Figure A - The standard REGEDIT interface presents simple options geared toward the average user.
If you've edited your WIN.INI file to add specific associations within the [Extensions] section, you may not realize that the associations defined by the Registration Database take precedence over those in WIN.INI. Because of this, and because Windows reads WIN.INI only when Windows starts, you'll want your application's installation program to specify associations using the Registration Database rather than the WIN.INI file.
The second REGEDIT interface, the one you'll see if you launch REGEDIT.EXE using the /v command-line parameter (verbose mode), displays a complex but comprehensive listing of each entry in the Registration Database, as shown in Figure B. This listing includes some rather obscure information that Windows uses to handle various OLE operations.
Figure B - REGEDIT's verbose interface displays detailed information about each of the Registration Database entries.
The third REGEDIT interface, the one you'll use from a
program, is purely a command-line interface. To use REGEDIT's
command-line interface, you'll simply use the form
REGEDIT /s FRED.REG
When you launch REGEDIT using the /s command-line parameter
(silent mode), REGEDIT suppresses all output and merges the REGEDIT
Entries file that appears immediately following the command-line
parameter (in this example, FRED.REG).
The format of an Entries file is significantly different from
that of the REG.DAT file. Entries files are simple text files
that describe new REG.DAT information. An Entries file begins
with the line
REGEDIT
and contains a series of key/value pairs, such as those shown in Figure C.
Figure C - The SETUP.REG file contains Registration entries for the standard Windows components.
In Figure C, you'll notice the
line that reads as follows:
HKEY_CLASSES_ROOT\.txt = txtfile
In this line, .txt is the registration entry key and
txtfile is the value. (Each line in an Entries file must
start with the label HKEY_CLASSES_ROOT. If a line doesn't
start this way, the REGEDIT application will consider that line
to be a comment.)
To enable File Manager to launch a given file type with a particular application (by double-clicking the file icon instead of launching the application first), you need to define a file association. A file association consists of two key/value entries: a File Extension entry and a Windows 3.1 Shell Subkey entry.
The example line from SETUP.REG that we mentioned above is an
example of a File Extension entry. The first part of the entry,
HKEY_CLASSES_ROOT\.txt
names the file extension that you want to identify. The second
part of the entry,
= txtfile
names the text description that you'll use in other Registration entries to specify this type of file. This text description is also known as the program ID for the file type.
If you re-examine Figure C, you'll see that the SETUP.REG file identifies both INI and TXT files as using the txtfile program ID. If you later decide to support a compatible file type that uses a different extension, you can create another File Extension entry that uses the same program ID, txtfile.
In a similar manner, you'll define the appropriate Shell Subkey entry. However, you'll need to define at least two key/value pairs for the Shell Subkey entry: a text description of the file format that will appear in File Manager's Associations dialog box, and a path and filename that File Manager will use to launch the application.
The first key/value pair names the txtfile program ID
that we defined in the File Extension entry,
HKEY_CLASSES_ROOT\txtfile = Text File
and specifies that File Manager will use the text "Text
File" to identify any of the txtfile types. The
second key/value pair,
HKEY_CLASSES_ROOT\txtfile\shell\open\command = notepad.exe %1
specifies that when File Manager (the Windows 3.1 file system's shell) issues the open command for a compatible file, Windows should launch the notepad.exe application and pass the compatible file's name in place of the %1 parameter. (If you've written complex batch files under DOS, you'll recognize the %1 symbol as the identifier for the first command-line parameter.)
If you want to support the Print command as well as the Open command
from File Manager, you'll simply repeat the second key/value
pair, replacing open with print. Then, you'll
add an appropriate command-line parameter to the value section
of the statement to force the application to print the document
instead of opening it. For example, the key/value statement
HKEY_CLASSES_ROOT\txtfile\shell\print\command = notepad.exe /p %1
launches Notepad, but it passes the /p
parameter just prior to the filename. The /p
parameter causes Notepad to open, prompt the user for printing
options, print the file, and then exit.
Now let's create a simple Registration Database Entries file that will register new associations between the Borland C++ Integrated Development Environment (IDE) and any source files that you have on your system. To begin, launch Windows' Notepad application by double-clicking its icon in the Accessories program group.
When the Notepad window appears, enter the information that appears in Listing A, but make sure you enter the last two lines of information on a single line. (Also, you may need to modify the path that we've given for the IDE, depending on how you installed Borland C++ on your system.)
Listing A: CPP.REG
REGEDIT HKEY_CLASSES_ROOT\.cpp = cppsource HKEY_CLASSES_ROOT\cppsource = C++ Source HKEY_CLASSES_ROOT\cppsource\shell\open\command = \BC45\BIN\BCW.EXE %1
When you finish entering this file, choose Save from the File menu, enter cpp.reg in the File Name entry field, and click OK. Choose Exit from the File menu to quit Notepad.
Since the Windows installation program doesn't create an icon for the REGEDIT.EXE application, you'll need to run it manually. To do so, choose the Run command from Program Manager's File menu, enter \windows\regedit.exe /s cpp.reg in the Command Line entry field, and click OK.
When the Run dialog box disappears, you may think that REGEDIT didn't run. That's because you ran it using the /s parameter, just like an installation program would. Appropriately, REGEDIT doesn't display any messages or windows when you run it this way.
To confirm that REGEDIT made the necessary changes, choose Run from the File menu again, but this time enter \windows\regedit.exe /v in the Command Line entry field. When the Registration Info Editor window appears, you'll see the new association information (without the HKEY_CLASSES_ROOT labels) at the top of the window, as shown in Figure D.
Figure D - Check the Registration Info Editor window to confirm that your new Registration Database entries are valid.
Every programmer wants to create the most professional and well-integrated
programs possible. By using the features of REGEDIT we've
shown here, you can create an installation program that customizes
your user's target systems with fully functional File Manager
associations.
Copyright (c) 1996 The Cobb Group, a division of Ziff-Davis Publishing Company. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Ziff-Davis Publishing Company is prohibited. The Cobb Group and The Cobb Group logo are trademarks of Ziff-Davis Publishing Company.